Testing of message-oriented services or functions or APIs, such as Web services or other event-driven computer programs or applications, generally requires interaction with a backend or enterprise system functional environment. The interaction of the message-oriented service is through an interface, such as one or more queries or inputs that are serviced by the backend system. However, such backend systems are rarely available to a developer or tester of applications which are consumers of such message-oriented services. The backend systems may not be available because they have not been developed yet, exist in a location not accessible by the developer or tester of the applications which consume the message-oriented services, and/or are not reliable due to being in an end-of-life phase and investments in those systems are restricted, for example. Additionally, it is often difficult, time-consuming, and costly to onboard backend systems and associated data in some testing environments.
Accordingly, functional or performance testing is often performed using test stubs which are computer program modules implemented to simulate the behavior of a message-oriented service through the interface and provide a response message as would otherwise be provided by the unavailable backend system. By simulating responses of backend systems to request messages, the test stubs abstract the functionality of the backend system(s) associated with the message-oriented service being tested or consumed. Accordingly, the test stubs are configured to provide a response irrespective of business or other logic typically provided by a backend system. Therefore, the test stubs are relatively less complex than corresponding portions of the backend systems and require fewer resources to implement in a testing environment.
However, custom stubs must be created for every interface due to the unique nature of each interface such as, for example, with respect to unique backend system queries and other interactions. Creating custom stubs for each message-oriented service is expensive and not extensible. Additionally, the process of creating the custom stubs is susceptible to error, adds an additional layer of complexity, and increases the project costs, which is undesirable in a testing environment.